A conventional network device is a black box and a control rich in flexibility for load balancing or deviation cannot be performed from outside. Thus, there was a problem in that, when a network size becomes greater, understanding and improving system behavior becomes difficult and designing and reconfiguration are accompanied by an enormous cost.
As a technique of resolving such subjects, a method is considered to separate packet transferring function and path controlling function of network devices. For example, by making a network device handle the packet transferring function and making a control apparatus separated outside of the network device handle the controlling function, a control becomes easier and a network rich in flexibility becomes able to be configured.
(Description of C/U Separation Type Network)
A C/U (Control plane/User plane) separation type network, in which an outside control device (control plane) controls a node device (user plane), is proposed as one network system with separated functions.
An OpenFlow™ network using OpenFlow™ technology in which network path control is performed by controlling a switch from a controller can be shown as an example of C/U separation type network. Details of OpenFlow™ technology is disclosed in Non-Patent Literature 1. It should be noted that OpenFlow™ network is only one example.
(Description of OpenFlow™ Network)
In an OpenFlow™ network, a control device such as an OpenFlow™ controller (OFC) operates a flow table related to path control of a node device such as an OpenFlow™ Switch (OFS) to control the node device behavior.
Hereinafter, for a simplification of description, an OpenFlow™ controller (OFC) will be denoted “controller (OFC)” and an OpenFlow™ switch (OFS) will be denoted “switch (OFS)”.
A secure channel, which is a leased line or a communication path protected by SSL (Secure Socket Layer) or the like, connects between a controller (OFC) and a switch (OFS). The controller (OFC) and the switch (OFS) transmit and receive an OpenFlow™ message conformed to (compliant with) OpenFlow™ protocol via the security channel.
A switch (OFS) in an OpenFlow™ network is an edge switch and a core switch, configuring the OpenFlow™ network and under control of a controller (OFC). A series of packet flow, from a reception of packet at an edge switch on entrance (Ingress) side of an OpenFlow™ network to a transmission of packet at an edge switch on exit (Engress) side, will be called a flow.
A packet can be read as a frame. A difference between a packet and a frame is only a difference of Protocol Data Unit (PDU). A packet is a PDU of “TCP/IP” (Transmission Control Protocol/Internet Protocol). On the other hand, a frame is a PDU of “Ethernet”.
A flow table is a table in which is registered a flow entry in which is defined a specified operation (action) to be performed to a packet (communication data) matching to a specified matching condition (rule).
A rule of a flow entry is defined by various combinations using some or all of a destination address, a source address, a destination port and a source port included in a header area of each protocol layer of the packet and is distinguishable. It should be noted that the above addresses include a MAC (Media Access Control) address and an IP (Internet Protocol) address. In addition to the above, information of entrance port (Ingress Port) can be used as a rule of a flow entry, too. In addition, a part (or the whole) of header area value of the packet showing a flow can be set with an expression such as a regular expression, a wild card “*” or the like as a rule of a flow entry.
An action of a flow entry shows an operation such as “output to a specific port”, “drop”, “rewrite header” or the like. For example, if identification information of exit port (such as an output port number, etc) is shown, a switch (OFS) outputs a packet to the corresponding port and if identification information of exit port is not shown, the switch (OFS) drops the packet. Alternatively, if header information is shown in an action of the flow entry, the switch (OFS) rewrites the header of the packet on a basis of the relevant header information.
A switch (OFS) in an OpenFlow™ network executes an action of a flow entry to a group f packets (a series of packets) matching to a rule of the flow entry.
(Subject in Existing OpenFlow™ Network)
Hereinafter, subject in existing OpenFlow™ network will be described.
(1) First subject: in an existing OpenFlow™ network, a controller (OFC) manages all the switches (OFS); consequently, a load of the controller easily increases and setting flow entry may take time.
Thus, a procedure may be taken such as, not setting all flow entries at a timing of detecting a packet, but setting a flow entry which can be set in advance not to time out and updating (rewriting) the flow entry at a timing of environment modification.
In this case, if only the controller (OFC) is made redundant and one flow table is shared by a plurality of controllers (OFC), controllers (OFC) need to synchronize between them the flow entry which is set and the flow entry synchronization function has to be supported by the controllers (OFC) side.
In addition, if the controllers are configured in a system with a redundant configuration (such as a fault tolerant system or a cluster system), when the system switches from an active system to a standby system, a status of synchronization between the old active system and the switch (OFS) and a status of synchronization between the new active system and the switch (OFS) has to be made identical, and this process takes time. It should be noted that the old active system is the controller (OFC) which switched from the active system to the standby system. In addition, the new active system is the controller (OFC) which switched from the standby system to the active system.
(2) Second subject: in addition, in an existing OpenFlow™ network, when a controller (OFC) stops, its influence may spread over whole network. Thus, a technology of making the controller redundant more freely is important or/and necessary. However, at present, such technology of making redundant is not established.
(3) Third subject: in addition, in existing OpenFlow™ network, a controller (OFC) manages whole the network. Consequently, a load of the controller (OFC) increases and performing load dispersion becomes important and necessary. However, at present, such technology related to a load balancing is not established.
(Subject Due to Difference of Flow Entry Setting Method)
In OpenFlow™, methods of setting a flow entry in a switch (OFS) can be roughly classified into two methods, a “reactive type” and “a proactive type”.
The “reactive type” is a method of setting all flow entries at a trigger of packet-in. In should be noted that packet-in signifies transferring a copy of the relevant packet to the controller (OFC) to request a path calculation for the packet to the controller (OFC). In the “reactive type”, when receiving an inquiry about a first packet (a new/first packet without corresponding flow entry) from the switch (OFS), the controller (OFC) calculates a path of the relevant packet set (flow) and registers a flow entry in a flow table of the switch (OFS) That is, the “reactive type” as used herein shows a “real-time flow entry registering” performed by the controller (OFC) in response to the inquiry from the switch (OFS) in an actual data communication.
The “proactive type” is basically a method of setting all flow entries which can be set in advance and adding minimal flow entry setting at a trigger of packet-in or the like in accordance with necessity. In the “proactive type”, the controller (OFC) calculates “in advance (before data communication starts)” a path of a specific packet set (flow) and registers a flow entry in a flow table of the switch (OFS). That is, the “proactive type” as used herein shows a “flow entry registration in advance” voluntarily performed by the controller (OFC).
Between those two methods, the latter is better in scalability and stability. However, in fact, in an occasion of system exchanging at a failure, it can be considered that a flow is already put (some packets are already controlled as a flow) and thus the controller (OFC) which became a new active device has to inherit flow entries from the old active device and set so that the present flow status does not conflict. Therefore, a mechanism of synchronization between controllers (OFC) is necessary and controller (OFC) implementation becomes complicated. In addition, only redundant configuration supported by the controller (OFC) can be configured.
In addition, if controllers (OFC) are mutually synchronized as above and share one connection, when a failure occurs and systems switch, a difference may occurs between the synchronization status in controllers (OFC) and flow entry setting status for the switch (OFS).
Thus, a synchronization process becomes necessary between the controller (OFC) which became the new active device and the switch (OFS).